1. Field of Invention
This application relates generally to software development and more specifically to tools for testing software.
2. Discussion of Related Art
As software programs are developed, it is often desirable to test the programs to determine that they operate as intended. As software programs have gotten larger and more complex, it has become more likely that a program will execute too slowly, consume too much memory or otherwise not deliver a desired level of performance even when all portions of the program produce the desired outputs.
It is often desirable to test the program to determine whether it delivers a desired level of performance. Where a software program does not deliver a desired level of performance, a performance engineer may analyze the program as it executes to identify portions that can be modified to improve performance.
To facilitate performance engineering, software development systems include tools that can “instrument” a program. “Instrumenting” a program generally involves inserting calls to special functions, called “probes.” Each probe records information about the operating state of the program in which the probe is inserted each time it is executed. For example, a probe may be inserted in a program before the program calls a particular function and a second probe may be inserted in that program after the call to that function. When these probes are executed, each may write into a log file the time at which it executed. By analyzing the log file, a performance engineer may determine the amount of time required to execute the function.
As another example, probes may be inserted at the beginning and end of each function. Information gathered by these probes may be used to analyze the number of times each function is executed or the execution time for each call to the function. Such performance information is important when analyzing a relatively complex program.
For the results obtained by analyzing an instrumented program to be a reliable indication of the performance of the program in actual operation, adding probes should disrupt the operation of the program as little as possible. Accordingly, probes are generally inserted into the binary or executable file containing the program to be analyzed. The binary file contains the program after it has been fully optimized and compiled. Therefore inserting probes does not alter the optimization or compilation processes.
To insert probes into the binary file, the binary file is disassembled to identify specific locations in the program where probes are desired. For example, a function table is often included as part of a binary file to specify the beginning of the instructions representing each function
Probes also should not introduce errors into the running program, such as by altering the storage of variables or disrupting the format in which information relied on by the executing program is stored. A software system in which application programs are written may impose various programming conventions, particularly concerning the altering of register values in functions.
For example, many widely available applications have been developed for the X86 processor family with a particular calling convention. To comply with this calling convention, a compiler processing a program to run on an X86 processor may implement each function with a prologue and an epilogue portion. In the prologue, the function pushes onto the stack the values in each register that the function alters. In the epilogue portion, the function restores the values of these registers by popping them off the stack. Any other routine or tools written to interact with such a function may assume that information is stored in accordance with the calling convention. If the information is not stored in accordance with the calling convention errors may result.
The specific calling conventions may be customized for the processor on which the program is intended to operate. For example, a calling convention may be designed to use instructions that the processor executes quickly. Accordingly, each platform formed by a combination of a software system and a processor on which that software system is intended to operate may have a different calling convention. For example, some platforms incorporate the processors that include the 64-bit extension of the X86 processor family. Such processors are available under names such as AMD64 or EMT64T These processors are collectively referred to as having the X64 extension. Platforms based on processors with the X64 extension may use a different calling convention than similar platforms based on the X86 processor without the extension.
It would be desirable to instrument a program developed for an X64 platform or other applications using calling conventions in which traditional instrumentation approaches could introduce errors.